OHNOLZA 숙박예약서비스(4) - 이미지 처리를 통한 성능 개선하기

(본 포스팅은 2023/11월에 작성된 포스팅입니다)

OHNOLZA 바로가기!
레포 바로가기!

블로그에서 다루지 않았지만, 리펙토링을 진행하며 프로젝트의 자잘자잘한 버그들을 잡아냈습니다. 아직은 개선할 사항들이 많고 무한스크롤, 스켈레톤과 같이 좀 더 모던한 기능들을 구현할 여지가 남아있니다만, 현재 기본적인 기능들은 정상적으로 작동하고 있기에, 다음 단계에서는 브라우저의 성능을 개선해보려 합니다.

프론트엔드 지망생으로서 요구 기능을 정확히 동작하도록 구현하는 것도 중요했지만, 그 못지않게 중요한 부분이 성능 개선입니다. 웹의 성능은 UX에 직결됩니다. 웹사이트의 반응 속도가 얼마나 준수한지에 따라 유저의 웹사이트 방문 시간이 달라지기 때문에 클라이언트와 밀접하게 연결된 프론트엔드로서 단순히 기능적인 부분만 구현하는 것이 아니라 성능까지도 고려할 필요가 있습니다.

1. 성능측정

성능 측정도구는 구글의 라이트하우스를 사용했습니다. 초기의 성능지표이다. 처참합니다.. 왜 이렇게 처참한 지표가 나온걸까요..

실제로 사이트는 결과와는 다르게 빠르게 반응하는 것 같습니다.
처참한 FCP와 LCP 속도에도 불구하고, 이미지가 빠르게 렌더링되고 있습니다..
그럼에도 이러한 결과가 나온다는 것은 성능 개선의 여지가 많다는 의미가 아닐까요

현재는 가상의 프로젝트이기 때문에 사용자가 없습니다. 따라서 웹사이트의 체감 성능이 나쁘지 않을 수 있었습니다. 그러나 만약 사용자 규모가 어느 정도 있다고 가정한다면, 최적화되지 않은 부분들로 인해 사용자 경험이 열악해질 가능성이 충분히 있습니다. 또한, 최적화할 수 있는 부분은 깔끔하게 처리하는 것이 당연하기 때문에 성능 개선을 실시합니다.

원인

라이트하우스를 사용하면 친절하게도 무엇이 잘못되었는지 잘 알려줍니다. 가장 문제가 되고 있는 부분은 이미지입니다.

사이트 특성

오놀자 메인페이지를 들어가보면, 숙소들이 리스팅되고 숙소의 사진들이 렌더링됩니다. UX를 고려하여 숙소 사진을 직관적으로 보여주기 위해 디자인 되었고, 각 숙소 정보들은 이미지 캐러셀을 통해 여러 이미지를 렌더링합니다. 하지만 이러한 디자인에 의해 웹의 성능에 안좋은 영향을 미치고 있습니다.

이미지 사이즈

아래와 같이 개발자도구를 열어보면, 불필요하게 큰 이미지를 가져오고 있음이 보입니다. 메이페이지에서 렌더링되는 이미지의 최대크기는 600x300px이 되지 않는데도 불구하고, 원본의 이미지 사이즈는 2배 이상 큽니다.

이러한 이미지를 메인페이지에서 수십장을 불러오니 성능에 안좋은 영향을 미칠 수 밖에 없는 것 같습니다..

2. 개선

어떻게 개선할 수 있을까 고민해봅니다. 아쉽게도 이미지 자체를 클라이언트에서 서버로 보내는 구조가 아닙니다. 따라서 처음부터 이미지 파일 자체의 크기를 최적화시켜주진 못한다.

어떻게 개선할 것인가?

1. 이미지 cdn을 통한 이미지 리사이징(보류)

: 이 방법이 가장 효과적이라 생각하지만 보류합니다. 이미지 cdn을 설정 후 이미지 리사이징을 고려해보았지만, 유료 서비스이기에 1000장 이상부터는 요금이.. 부과된다는 큰 문제가 있습니다.

2. lazy-loading 적용

: 메인페이지의 숙소 이미지는 캐러셀로 구성되어 있습니다. 따라서 첫 번째 이미지가 아니라면, 한꺼번에 로딩될 필요가 없습니다. 즉 2 번째 이미지 부터는 지연로딩을 적용할 수 있게 됩니다. lazy-loading은 현재 브라우저에서 지원하기 때문에 간편하게 적용할 수 있어뷰 뷰포트에 감지되기 전까지 이미지 로딩을 지연시킬 수 있습니다. 결과적으로 FCP를 개선할 수 있을 것이라 기대됩니다.

3. 캐러셀에 최대 이미지 개수 설정

: 현재 숙소에 제공되는 이미지 만큼 동적으로 캐러셀의 길이가 늘어나고 있습니다. 즉 이미지가 많을수록 메인페이지에서도 많은 이미지를 불러오게 됩니다. 숙소가 제공하는 디테일한 이미지들은 상세페이지에서도 충분히 보여줄 수 있기 때문에, 캐러셀의 최대 크기를 조정하여 이미지 요청 또한 줄여주었습니다. 평균적으로 3개정도의 이미지를 가져오기 때문에 다이나믹한 변화는 없겠지만 최선을 다해봅니다..

코드

위의 사항을 적용한 코드입니다. 크게 바꾼 부분은 없습니다. 캐러셀의 길이를 조정하고, 첫번째 이후 사진에 대해서 지연 로딩을 적용했습니다.

3. 결과

적용 전

: 메인페이지에서 캐러셀로 인해 보이지 않을 이미지를 포함한 모든 이미지에 대한 요청이 한번에 이루어지고 있습니다. 이미지에 대한 요청이 50건 정도 됩니다. 용량이 커다란 이미지가 50개 이상 로딩 되어야 합니다..

적용 후

: 불러오는 이미지의 건수가 확연하게 줄어들었습니다. 첫 렌더링 되는 이미지 16건 만이 렌더링 되며, 캐러셀 2 번째 이상의 이미지부터는 지연 로딩이 적용되고 있습니다. (자세히 보면 요청 건이 200건이 넘지만, 대부분 캐싱된 데이터여서 무시해도 좋습니다.)

성능 변화

: 아직 페이지의 성능은 더 높은 개선이 필요하합니다. 그러나 이미지 성능개선 시도 후 유의미한 변화는 LCP에 있었습니다. LCP의 정의대로 현재 사이트에서 마지막으로 불러운 가장 큰 이미지가 로딩되는데 걸리는 시간이 약 9초 가량 개선되었음이 확인됩니다. lazy-loading에 의해 초반 로딩되는 이미지의 개수 자체가 줄었기에 가능한 일이었습니다.

4. 정리 및 회고

메인 페이지는 사용자가 처음 들어오는 장소인만큼, 양호한 성능을 유지시키는 것이 중요하다고 생각합니다. 특히, 이번 프로젝트의 경우 메인페이지에 많은 이미지를 노출시켰습니다. 깔끔한 UX를 위함이였지만, 성능에 대한 이슈를 간과하고 시각적인 UX만을 고려한 결과 성능에는 아쉬운 결과를 보여주게 되었습니다.

만약 사전에 이를 고려할 수 있었다면, 서버 측과 이미지 최적화에 대한 방법을 논의해본다던지 다량의 이미지 노출에 조금 더 보수적으로 접근한다던지 않았을까 싶습니다. 결과적으로 큰 개선은 달성하지 못해 한편으로 아쉬움이 많이 남습니다만, 성능 고려에 대한 경험을 얻어가는 프로젝트입니다.